R u Ready? HS2025 | Psychologie der Digitalisierung - Einheit 4

Sandra Grinschgl, Aaron Friedli, Lars Schilling

R u Ready? Reproduzierbare Datenaufbereitung und -analyse mit R

HS 2025


LV-Leitung: Dr. Sandra Grinschgl / MSc. Aaron Friedli
Tutor: BSc. Lars Schilling


4. Einheit, 8.10.2025

Fragen zum Datenanalyseplan & Codebook:

Heute:

Hands On!

🎯 Ziel: Heute mindestens bis zum Daten-Mergen und Speichern kommen!

🏃 Für alle, die schneller fertig sind: Coding Basics, Funktionen und Styler

✈️ Für besonders Schnelle: Weiterarbeiten am Codebook / Peer-Feedback

Daten einlesen

  • Code immer im Skript abspeichern!

  • Ausführung alleine in der Konsole reicht nicht

  • Bei Einlesen über Environment, Code in Skript kopieren!

Plenum: Wie funktionieren Joins?

  • cbind() vs. full_join()

  • cbind() verbindet Datensätze spaltenweise – warum ist das suboptimal?

  • full_join() Nimmt alle Variablen aus beiden Datensätzen. Um die Datensätze korrekt zu verbinden musst du einen Schlüssel festlegen.

full_join()

Was ist der Schlüssel?

Eine gemeinsame Variable die in beiden Datensätzen vorhanden ist, mit der RStudio erkennen kann welche Werte miteinander verbunden werden müssen.

data_cb <- read_delim("data/raw/data_cb.csv", delim = ";")
data_vp <- read_delim("data/raw/data_vp.csv", delim = ";")

dat_full_1 <- full_join(data_cb, data_vp, by = "code")
head(dat_full_1)
# A tibble: 6 × 5
   code cb_sum cb_propcorrect vp_sum vp_propcorrect
  <dbl>  <dbl>          <dbl>  <dbl>          <dbl>
1     1     26          0.722     33          0.917
2     2     27          0.75      27          0.75 
3     3     30          0.833     33          0.917
4     4     27          0.75      31          0.861
5     5     25          0.694     32          0.889
6     6     23          0.639     24          0.667

Beispiel

df1 <- data.frame(id = c(1, 2, 3),
                  name = c("Anna", "Ben", "Chris"))

df2 <- data.frame(id = c(2, 3, 4),
                  score = c(80, 90, 70))

full_join(df1, df2, by = "id")
  id  name score
1  1  Anna    NA
2  2   Ben    80
3  3 Chris    90
4  4  <NA>    70

Unterschiede zwischen den diversen Joins:

Unterschiede zwischen den diversen Joins:

Unterschiede zwischen den diversen Joins:

Unterschiede zwischen den diversen Joins:

Check-in:

  • Nun sollte jede/r einen Datensatz dat_full haben, der alle 7 Einzeldatensätze beinhaltet mit 159 Versuchspersonen (= Zeilen) und 36 Variablen (= Spalten).

  • Checkt mit euren Peer-Partner:innen/Sitznachbar:innen!

  • Mit diesem Datensatz werden wir die Analysen von Grinschgl et al. (2020) durchführen.

  • Zu diesem Datensatz sollt ihr bis zum 22.10. den ersten Entwurf für das Codebook schreiben!

Fehlererkennung in R

Der Code läuft nicht. Wie könnt ihr vorgehen um den Fehler zu identifizieren und beheben?

  • Lies die Fehlermeldung!

Überprüfe:

✅Tippfehler

✅Klammern

✅Syntaxfehler

✅Datentypen

✅Pakete

Googeln hilft oft weiter!

Fehlermeldungen lassen sich einfacher googeln, wenn R auf Englisch eingestellt ist:

  • 👉Sys.setenv(LANGUAGE = "en")
  • oft ist es auch hilfreich, das Betriebssystem anzugeben: sessionInfo()

Fehlererkennung in R – Tipps

  • class() / str() zur Objektprüfung 👉

    In mean.default(x) : argument is not numeric or logical: returning NA
  • Funktionen schrittweise testen

  • Argumente weglassen → Fehlerquelle finden

  • Zwischenergebnisse mit print()

Code Diagnostik:

R-Studio gibt Hinweise!

R-Resourcen

Large Language Models & Datenanalyse

  • Modelle wie ChatGPT

  • Berechnen Wahrscheinlichkeiten für Wörter und erzeugen dadurch Text, der menschlich wirkt.

  • ABER:

    • Verstehen keine Bedeutung

    • Wissen nicht was inhaltlich korrekt ist

Vibe coding

👉KI in natürlicher Sprache prompten ohne den generierten Code zu prüfen oder zu verstehen.

Gefahren von Vibe coding

KI - LLMs (ChatGPT, Copilot, Rtutor)

💚 Vorteile

  • Generieren schnell viel Code

  • Code häufig syntaktisch korrekt

  • On-Demand-Assistenz für Fragen aller Art

  • Reduziert Einstiegshürden

  • Unterstützung bei Debugging und Error Handling

  • Tutoring-Funktion –> siehe Prompts

💔 Nachteile

  • Unreflektiert Code übernehmen → Lerneffekt sinkt

  • Keine Garantie für Korrektheit → Code kann plausibel wirken, aber methodisch unangemessen sein.

  • Overreliance / Cognitive Offloading → Reduziertes Verständnis dessen, was man tut

  • Nicht immer Best-Practice-Beispiele → Verletzung wissenschaftlicher Standards

  • “Fast but Flawed”

  • ⚠️Datenschutz: Niemals sensible Daten in LLMs hochladen ⚠️

Sinnvolle Nutzung von KI im Datenanalyseprozess:

  • 💚Sinnvoll: Unterstützend – nicht ersetzend

    • Kontrolle einfacher Fehler (Klammern, Typos)
    • Erklärung von Code und Syntax
    • Hilfe bei Fehlersuche (Debugging)
    • Kommentierung und Dokumentation
  • 💔Nicht sinnvoll: Ersatz statt Unterstützung

    • Generierung ganzer Analyse-Skripte

    • Automatische Auswahl von Methoden oder Tests

    • Interpretation statistischer Ergebnisse durch KI

    • Erstellung kompletter Berichte oder Diskussionen

    • Hochladen sensibler Daten

    • Unkritisches Übernehmen von Output

Github CoPilot in R

  • Voraussetzung ist ein Account sowie ein Copilot-Abo (kostenlos für Studierende) auf GitHub.
    GitHub ist ein Clouddienst von Microsoft, spezialisiert auf das Teilen und gemeinsame Bearbeiten von Code:

    https://github.com/

  • Eine Anleitung zur Einrichtung von GitHub Copilot in RStudio findet ihr hier:
    YouTube-Link (1:40–2:36)

  • Rechtliche Informationen für Studierende der Universität Bern findet ihr unter:
    Generative KI Uni Bern

ChatGPT in R

Verwendung von LLMs

Peer Feedback zum Datenanalyseplan

📋To Do’s:

  • Musterlösung anschauen! (siehe Ordner Abschlussprojekt auf Ilias)

  • Datenanalyseplan des Partners/der Partnerin bis 15.10. durchschauen und kommentieren (am besten mit Word oder PDF Kommentaren)

  • Upload auf Ilias mit Kommentaren+ Weitergabe an Partner:in per Email

  • Auch persönliches Feedback erwünscht 👉 selbstorganisiert

    Selbständigkeit: Wir geben kein Feedback, bei Fragen auf uns zukommen (Forum, Sprechstunde etc. nutzen)

Peer Feedback zum Datenanalyseplan

  • Klarheit und Verständlichkeit (z.B. sind alle Begriffe und Konzepte ausreichend erklärt? Gibt es verwirrende oder unklare Formulierungen?)

  • Vollständigkeit (z.B. wurden alle notwendigen Fragen ausreichend beantwortet? Fehlen Informationen?)

  • Reproduzierbarkeit (Ist der Plan so formuliert, dass er von einer anderen Person nachvollzogen und reproduziert werden kann?)

Peer Feedback Regeln

  • Gib fundiertes, konstruktives und gut strukturiertes Feedback!

  • Fokus sollte auf inhaltlicher Qualität und Übereinstimmung mit den Anforderungen liegen, nicht auf persönlichen Präferenzen.

  • Verbesserungsvorschläge sind gewünscht, kein „Schön reden“ notwendig –> wir wollen dazu lernen!

  • Verbesserungsvorschläge sollten möglichst konkret sein.

  • Bleibt aber natürlich sachlich und verwendet eine respektvolle Sprache!

  • Auch Lob für besonders gute Abschnitte darf nicht fehlen. Feedback ist ein Lernprozess, auch für den Gebenden. Seit bereit, euer Feedback anzupassen, wenn die andere Person es anders versteht oder weitere Informationen liefert.

  • Peer Feedback sollte nicht nur auf die aktuelle Aufgabe abzielen, sondern auch helfen, den Lernprozess der beteiligten Personen langfristig zu verbessern

Heute haben wir:

  • Datensätze gemerged und diverse joins kennengelernt

  • Tools für die Fehlerdiagnostik in R kennengelernt

  • Uns mit Ressourcen und dem Umgang mit LLMS befasst

Abfrage Muddiest Points

  • Denke an die bisher besprochenen Inhalte zurück – was ist dir unklar geblieben? Was sollten wir noch einmal besprechen?

  • Denke sowohl an die R Hands On Sessions als auch die theoretischen Inhalte (z.B. Open Science, Datenanalyseplan, Codebook).

  • Notiere bitte max. drei konkrete Punkte. Falls du Vorschläge/Ideen zur Aufarbeitung dieser Punkte hast, gib diese auch gerne an.

  • Umfrage auf ILIAS (siehe EH 4) bis Sonntag 12.10. 23:55

Zusammenfassung der To Do’s

  • Muddiest Points Umfrage bis Sonntag 23:55

  • Peer Feedback Datenanalyseplan bis Mittwoch

  • Selbstständiges Durcharbeiten des Hands On Block 2 bis Mittwoch

Referenzen:

Arslan (2025, June 4). One lives only to make blunders: Resources for learning R. Retrieved from https://rubenarslan.github.io/posts/2025-06-04-resources-for-learning-r/